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(57) Abstract: The invention relates to configuration management and updating a directory service in a distributed platform. The 
known LDAP (Lightweight Directory Access Protocol) is used for managing the configuration directories of processes and CNS 
(Coiba Notification Service) for handling the notifications of changes in the configuration directories. The configuration directories 
are situated in a directory service, which is a physically distributed, logically cenfralized repository (containing databases). Pro- 
cesses, monitoring elements and management elements, etc. use the directory service to get configuration information for their use. 
When there are changes in the configuration directory of a node, a notification message concerning the change is sent to CNS. CNS 
distributes the notification message to the processes that are interested in knowing the change. 
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Configuration Management in a Distributed Platform 
Field of the Invention 

This invention relates to configuration management and updating 
5 a directory service in a distributed platform. A distributed platform can be a 
large network, such as a telecommunications network or a datacommunica- 
tions network where databases, servers and users are located in a large 
area. 

1 0 Background of the Invention 

Figure 1 illustrates an example of how the configuration of nodes 
in a telecommunications network is handled at present. Nodes are network 
elements, such as servers, switches and multiplexers. A network manage- 
ment system, NMS, (1) handles the configuration of the nodes (2) through a 

15 telecommunications management network. Each node contains processes 
(3) for handling process-specific tasks. Configuration is needed when a node 
is taken into use and when specific events, such as changes in a network 
structure, assembling new versions and so on, occur. 

In a configuration event one or more processes in a node may 

20 need changes. The NMS handles the changes, i.e. configuration, process by 
process. In other words, configuration has to be done separately for each 
process. A situation may arise where a change of configuration generates a 
need to make configuration for another process, in the same or another 
node. Thus, the NMS needs to make the changes for both the processes in 

25 this case. 

In another possible situation a node, which is a server, has a 
backup node elsewhere in the network, in this case, configuration information 
must be equal in both the nodes, after the changes of configuration too. So at 
present, configuration and updates are matched for each node. This can be 
30 reasonable if there are only a few processes in a node, but when the number 
of processes is going to be considerable, configuring each node separately 
becomes a heavy process, not to mention backups. The goal of the invention 
is to alleviate these drawbacks. This is achieved in a way described in the 
claims. 

35 
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Summary of the Invention 

In the method according to the invention the known LDAP (Light- 
weight Directory Access Protocol) is used for managing the configuration di- 
5 rectories of processes and CNS (Corba Notification Service) for handling the 
notifications of changes in the configuration directories. The configuration di- 
rectories are situated in a directory sen/ice, which is a physically distributed, 
logically centralized repository (containing databases). Processes, monitoring 
elements and management elements, etc. use the directory service to get 

10 configuration information for their use. However, LDAP does not support 
sending notifications of changes so CNS is tied to LDAP for handling the 
changes In the configuration directories. 

When there are changes In the configuration directory of a node, a 
notification message conceming the change is sent to CNS. CNS distributes 

15 the notification message to the processes that are interested in knowing the 
change. After receiving the message, the processes can update their con- 
figuration. 

The composition of LDAP and CNS brings modularity to the con- 
figuration management. An arrangement according to the invention can be 
20 constructed to be transparent so that it is independent of different technolo- 
gies used in nodes. CNS handles the distribution of run time changes to 
processes. 



Brief Description of the Drawings 

25 In the following the invention is described in more detail by means 

of Figures 1 - 6 in the attached drawings where 



Figure 1 
Figure 2 

30 

Figure 3 
Figure 4 
Figure 5 

35 Figure 6 



illustrates an example of configuration management at present, 
illustrates an example of configuration management according to 
the invention, 

illustrates an example of the hierarchical naming model of LDAP, 
illustrates the principle of a notification service, 
illustrates an example of a node according to the Invention, im- 
plemented using Java, 

Illustrates an example of a method according to the Invention. 
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Detailed Description of the Invention 

Figure 2 shows an example of the configuration management ac- 
cording to the invention. Because the configuration management works In a 
distributed platform, there can be different physical implementations. For ex- 
5 ample, databases can be situated in servers or in one place, illustrating other 
choices of implementation than Figure 2. 

The configuration information (CD, 211) of Servers 1 and 2 
(21,22) has been stored in a configuration database (CDB) (24). (The data- 
base belongs to a distributed directory service (210).) When configuration is 

10 desired to be changed, new parameters are stored into the database. A 
command to change the configuration information can come from the net- 
work management (NMS) (27) or an entity, such as a single process in a 
node that is allowed to do specific changes in configuration data. However, 
the LDAP (29) does not support distribution of the changes to the processes 

15 that are interested in knowing the changes, i.e. the changed parameter val- 
ues. 

The source of the changes, i.e. the network management or the 
entity, sends a notification message to the CNS (28). Other processes that 
are interested in changes of these particular parameter values get the notifi- 

20 cation from the CNS after which they can change their own parameter val- 
ues. So the notification message contains the new parameter values. Figure 
2 also shows a back-up server (23) for Server 1 and a back-up configuration 
database (25). The back-up server must contain the same information as the 
primary database, so the changes in the configuration information must be 

25 updated into both databases. The changes in the back-up system can be 
done through the CNS. 

Configuration management is based on a directory service using 
LDAP. The directory service is a physically distributed, logically centralized 
repository of infrequently changing data. LDAP is a protocol to retrieve and 

30 manage directory information. Recently and still, managing corporate directo- 
ries is a bit of a mess due to the variety of directories from different manufac- 
tures. LDAP offers a good way to access different directories. Although no 
single directory specification is apparent to become the global standard, 
many manufactures have started to support LDAP as an access mechanism 

35 for their directory products. 
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A powerful feature of LDAP is hierarchical naming of directories, 
which provides an efficient referencing and retrieval of collections of related 
information, such as system's name, node's name and process's name. Fig- 
ure 3 shows an example of the naming of the system according Figure 2. For 
5 example, the name of Process 1 in Server 1 is System/Server 1/P1. The 
naming system makes It possible to achieve a desired LDAP directory in a 
simple way. 

A drawback of LDAP is that when changes occur in an LDAP di- 
rectory, It does not inform processes and components, whose configuration 

10 information is in that directory, of the changes. Due to this, a notification ser- 
vice, such as CNS (Corba Notification Service), is needed. 

Corba is an architecture intended for handling interoperability 
among a continuously proliferating number of hardware and software prod- 
ucts. Corba allows applications to communicate with one another, no matter 

15 where they are located. Corba includes a notification service, CNS, that can, 
for example, transmit infomriation of a change from a supplier (a directory, 
process or component where the change happened) to a consumer (a direc- 
tory, process or component) who needs that information. 

Figure 4 shows an example of how CNS works. Consumers (41) 

20 are entities in a system, which are interested in knowing changes in another 
entity. Let's call a change or an occurrence that may be of interest to con- 
sumers an event. A consumer can, for example, be a process, database or 
another component in a distributed platform. Suppliers (42) are entities that 
generate events. A component can be a supplier and consumer at the same 

25 time concerning different events. The suppliers generate notification mes- 
sages of events to the CNS (43) that then fon/vards them to the consumers. 

The event communication comprises two models: a push and pull 
models. In the push model the supplier initiates the transfer of events to the 
consumers and in the pull model the consumer requests the events from the 

30 suppliers. The notification service enables the customers to specify exactly 
what events are interesting, i.e. CNS offers a filtering function. In other 
words, the suppliers and consumers are registered in CNS. 

As mentioned before, the invention can be implemented in many 
ways. One way to create the functions of the invention is to use Java, an ob- 

35 ject-oriented programming language. In this context Java has been used as 
an example of a tool used for the implementation. For understanding the next 
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description of an implementation of the invention, basic structures of the Java 
language should be kept in mind. An object is a software component that 
usually contains an executive code and data. In an object-oriented language 
actual objects are not defined, but classes of objects are. A class is a tern- 
5 plate for multiple objects vy^ith similar features. It can be said that a class de- 
scribes all common features for all objects in the class. So, a single object is 
a concrete representation of the class, in other words an instance. 

Methods or logic are functions, i.e. executable codes that operate 
on a class or an object. A stream or channel is a path of communication be- 

10 tween the source of some information and its destination. Java contains sev- 
eral rnputstream and outputstream classes for defining different streams. Se- 
rializing is a feature in the Java environment that makes it possible to save a 
state of an instance of the class (the concrete representation of a class) in 
the form of a byte-line. Serialized instances can be deserialized making it 

15 possible to use the saved class representation later. To sum up, a Java ap- 
plication comprises classes, which refer to objects. One of the classes is the 
"route" class, which contains basic methods of the application and makes it 
possible to get the other classes that belong to the application. Also the next 
definitions should be kept in mind: 

20 

JSLE Java Service Logic Environment that provides execution of ser- 
vice logic, 

SLOP Service Logic Program in JSLE, which provides a platform for 
actual logic, 

25 SLC Service Logic Component in SLOP, which is a piece of reus- 

able logic. A collection of SLCs models service logic. 

Figure 5 illustrates an example of a node implemented using Java. 
LDAP and CNS. The node includes JSLE (51) that provides execution of dif- 

30 ferent processes in the node. SLOP (a class) (52) represents a single proc- 
ess and provides a platform for actual logic. SLCs (53) are a piece of reus- 
able logic, i.e. objects, including configuration information. The configuration 
data is stored In a directory service (54) using a physical database (55). The 
configuration data contains information about the installed SLOPs, which are 

35 found from a database using the LDAP (56) as an access method. The JSLE 
provides a mechanism to send customized events to a CORBA notification 
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service (57). The notification service uses streams, called notification chan- 
nels, for receiving and sending events. The notification service also supports 
the definition of filters for events. The consumers of these events then join 
the event channels asynchronously. The SLOPs can be registered as con- 
5 sumers for joining the event channels. 

Figure 6 illustrates an example of a method according to the In- 
vention. First, a need to change configuration Information comes from the 
network management or a single component, such as a process, if the com- 
ponent is allowed to do simple changes in the configurafion Information itself. 

10 The change (or changes) has to updated (61) in the configuration directory. 
So the component or the network management sends updating infomiation to 
the configuration directory. 

Because the configuration directory used (LDAP) does not support 
distributing the changes to the relevant processes, the component or network 

15 management has to send (62) a notification message concerning the change 
to the notification service used. The message includes information of the 
relevant processes and channels for distributing the notification. The notifica- 
tion service forwards (63) the notification message to the relevant processes 
that are interested in knowing the change. After receiving the notification 

20 message, the processes can update (64) their configuration. 

The composition of LDAP and CNS brings modularity to configura- 
tion management. Changes can be distributed to any elements that are inter- 
ested in knowing and updating the changes even during a run time. Due to 
this, the updating of back-up systems can be done in real-time, without re- 

25 peating the actual configuration action. 

There are several embodiments concerning which entity is in 
charge of being the supplier for the said message concerning the change. 
Several embodiments can be thought of. 

In an embodiment of the invention the client requesting a change 

30 to the information in the directory (LDAP) can be made responsible for pro- 
viding to the notification service the message concerning the change. In this 
embodiment the client requesting a change to the infomiation In the directory 
first request the change to the directory and then provides to the notification 
service the message concerning the change. Of course the order of these 

35 steps can be inverted. For example, the client when being informed from the 
directory service that the change request has been accepted and that the da- 
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tabase has been updated supplies the message concerning the change to 
the notification service. 

In another embodinnent of the invention the directory service has a 
front end process or a proxy or a mediator service which receives the change 
5 requests to the information In the directory. The front end process is respon- 
sible for supplying to the notification service the message concerning the 
change for each accepted update to the directory service. In this embodiment 
the front end process can in fact have a Corba interface via which the 
changes to the directory service are issued. In this interface there can be, for 
10 example, methods that correspond directly to the operations of the directory 
service. 

In yet another embodiment of the invention the directory service it- 
self supplies the message concerning the change to the notification service. 
In this embodiment, the directory service could have a first interface which is 

15 in accordance with the operation formats from the directory access protocol 
(e.g. LDAP) and a second interface which is used to convey change notifica- 
tion messages to the notification service. 

In yet another embodiment of the invention, the notification service 
is used to validate changes to the data in the directory. This means that a no- 

20 tification concerning the change is notified to the owner of the particular data 
item which is being updated. By the data item owned is meant, for instance, a 
partition within the overall directory, a part of the overall directory information 
tree, a specific entry, specific attributes within specified entries or specific at- 
tributes within a specific entry. The data item owned could comprise all the 

25 attributes within the directory having a specific attribute type. For instance, a 
given attribute type could be assigned to a given owner process. This means 
that all changes to attributes of that given type would be reported to the 
owner. 

When receiving the notification, the owner checks that the change 
30 conforms to rules concerning the value ranges and semantics of the data. 
For instance, the owner may check from attribute value updates that the up- 
date conforms to the value ranges imposed. If the value to be updated to the 
directory for the attribute conforms to the rules, the owner acknowledges the 
update and the information is updated to the directory. The notification to the 
35 owner of the data item can be issued by the directory service itself, the 
updating process, or by a front end process or mediator of the directory. The 
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owner of the data item can be specified in the directory in association with 
the data item. Alternatively, there could be a separate part of the directory 
which lists attribute types and their owners. It might be possible that the 
owner is determined otherwise by mapping the attribute type to the owner 
5 process using e.g. a separate table. 

It should be noted that the Invention is not restricted to the man- 
agement of configuration information within the directory service. The inven- 
tion could as well be used in other applications such as for storage of infor- 
mation elements like E-mail addresses and names, telephony names, num- 

10 bers and temninal addresses. Generally, the directory can store address in- 
formation for entities (i.e. processes or nodes) implementing some telecom- 
munication services. The directory can also store informational attributes as- 
sociated with these aforementioned infomiation elements such as altemative 
addresses or contact criteria. 

15 Although, the invention is described in the text as an implementa- 

tion created by Java and using Corba notification service and LDAP, it is evi- 
dent that other corresponding programming languages, directory access pro- 
tocols and notification services can be used. An arrangement according to 
the invention can be constructed to be transparent so the arrangement is in- 

20 dependent of the different technologies used in the nodes. Due to these, the 
invention can be used in many different implementations, in the scope of the 
inventive idea. 
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Claims 

I. A method for updating a directory service in a system compris- 
ing several clients and at least one directory service containing information 
that the clients use, characterized in that the method contains the 

5 steps of 

- registering the clients which are interested in updates concern- 
ing at least a portion of the information in the directory service, 

- updating the directory service by a client, 

- sending the update information to the registered clients. 

10 2. A method according to claim 1, characterized in that 

the registering step and the sending step are performed in a notification ser- 
vice. 

3. A method according to claim 1 or 2, characterized In 
that In the updating step a connection to the directory service is created by 

1 5 using a directory access method. 

4. A method according to claim 3, characterized in that 
LDAP is used as the directory access method. 

5. A method according to claim 1-4, characterized in that 
the updating step is accomplished via a mediator service. 

20 6. A method according to claim 5, characterized in that 

the mediator service sends the updating information to the notification ser- 
vice. 

7. A method according to claim 5, characterized in that 
the mediator service uses the standard interface of the directory service. 
25 8. A method according to claim 6, characterized in that 

the mediator sen/ice uses the standard interface of the notification service. 

9. A method according to claim 2, 6 or 8, c h a r a c t e r i z e d in 
that the notification service filters the clients that are interested in knowing 
the updated information. 
30 10. A method according to claim 9, characterized in that a 

CORBA notification service is used as the notification service. 

II. A method according to claim 1-10, characterized In 
that the clients use program classes and objects for creating the functions of 
each client, the classes and objects Including the client specific Information. 

35 
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12. A method according to claim 11, characterized in that 
Java programming language is used for creating the classes and objects. 

13. A method according to claim 2-12, characterized in 

that 

5 a) the client sends a request for updating to the directory service, 

b) the client sends a message concerning the update to the notifica- 
tion service. 

14. A method according to claim 2, characterized in that 

a) the client sends a message concerning the update to the notifica- 
10 tion service, 

b) the client sends a request for updating to the directory service. 

15. An arrangement for updating a directory service in a system 
comprising several clients and at least one directory service containing in- 
formation that the clients use, characterized in that the arrangement 

15 includes 

- first means for registering the clients which are Interested in 
updates concerning at least a portion of the information in the 
directory service, 

- second means for updating the directory service, 

20 - third means for sending the update Information to the regis- 

tered clients. 

16. An arrangement according to claim 15, characterized 
in that the arrangement further includes a notification service adapted (1) to 
receive the update Information, and (2) to send the update information to the 

25 registered clients. 

17. An arrangement according to claim 16, characterized 
in that the notification service comprises means for registering update infor- 
mation and the first means. 

18. An arrangement according to claim 17, characterized 
30 in that the notification service further comprises means for associating the 

registered update information with the registered clients. 

19. An arrangement according to claim 18, characterized 
In that the notification service further comprises means for filtering the clients 
that are Interested In the updated Information. 

35 20. An arrangement according to claim 16-19, character- 

ize d in that the arrangement further comprises a mediator service for han- 
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dling updating tasks (1) between the clients and the directory service, and (2) 
between the directory service and the notification service. 

21 . An arrangement according to claim 20, characterized 
in that the mediator service further comprises means for handling updating 

5 tasks between the clients and the notification service. 

22. An arrangement according to claim 16 - 19, character- 
ized in that a CORBA notification service is used as the notification ser- 
vice. 

23. An arrangement according to claim 15-22, character- 
10 i z e d in that the clients comprise means for creating functions and means 

for containing the client specific information. 

24. An arrangement according to claim 16 - 19, character- 
ized in that the directory service comprises the notification service. 
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